A number of protocols have been developed to provide reliable packet communications between two user entities, especially where there is an unreliable communications link. The Time Sequence Protocol (TSP) is a high performance data transport protocol that is suitable for use as a link layer protocol for packet communications. The TSP is particularly suited for use over a link between two end users in a point-to-point communication environment where the link is subject to severe degradation due to interference. Such interference may be caused by environmental conditions, such as the weather, or physical impediments, such as buildings, bridges or the like, that prevent a clear link between a COTM terminal and another terminal, whether a satellite, other COTM terminal or stationary terminal. For example, in the communications system 100 illustrated in FIG. 1, a satellite 101 in geostationary orbit may be in communication with a plurality of COTM terminals COTM1-COTM4 as well as fixed site terminals FS1, FS2, the latter being coupled to the Internet 102. The fixed site terminals FS1 and FS2 are shown with large dish antennas because this is typical practice, although one of ordinary skill would understand that the fixed sites can employ small antennas if the link budget allows. The mobile terminals generally require steerable antennas to compensate for the motion of the platform. However, buildings B1 and B2 may serve to block one or more of the links between the satellite 101 and COTM terminals and create an outage, as depicted by the dashed lines. The TSP uses retransmission strategies to achieve a desired throughput and delay performance where packets are lost due to interference with an established point-to-point link. However, TSP is not applicable to network communications where links are controllably opened and closed, nor is it concerned with congestion on links since each link is established point-to-point. Moreover, even though point-to-point, end point applications communicate indirectly, via the link layer, the TSP cannot provide direct application to application communication.
The transmission control protocol (TCP) is well known standard for Internet applications and is represented by published standards that are incorporated herein by reference. The TCP protocol is combined with the Internet protocol (IP) to establish a general basis for network communications (TCP/IP). In a TCP-based system, end users enter into and depart from the network, for example by signing on to the Internet at a workstation, and the links that provide the communication between end users can open and close frequently as transmitted packets are switched. While such flexibility provides advantages, it also creates a problem with congestion on links as demand for capacity rises.
An example of a TCP based network is illustrated in FIG. 2 where a system 200 includes a satellite 201 that is in wireless communication with terrestrial satellite terminals 210, 220 over links 202, 203 so that end user workstations or servers 230, 240 may communicate with each other. The satellite terminals 210, 220, which may act as IP routers as would be known to those skilled in the art, are coupled to the satellite 201 via links 202, 203 through a satellite physical layer 211, 221, which in turn couples pairs of IP layers 212, 213 and 222, 223 to a respective Ethernet layer 214, 224 for communication via a local area network. The Ethernet layer 214 may couple directly via link 216 to a similar layer 231 in the workstation server 230 or to a similar layer 241 via links 251, 252 through the Internet 250. Each workstation or server has appropriate IP layers 232, 242, TCP layers 233, 243 and applications 234, 244. The applications may talk directly to each other via the transport layer, thereby providing a significant advantage over the TSP-based system, which only uses the link layer for communications. In the illustrated system, TCP flow control and acknowledge message exchange is provided end-to-end.
Since network links necessarily extend into the wireless domain, appropriate consideration must be given to the unique problems created when the TCP protocol is applied to a wireless network. Applying a standard transmission control protocol directly over a long delay link, such as those encountered in a ground to satellite link for example, results in poor performance due to many factors related to interference or the like. If a communication link is also subject to operational degradations, such as service outages, then network protocol performance is further diminished. For example, in a TCP protocol communication system supporting COTM terminals in moving vehicles, outages or blockages will occur when the vehicles pass under bridges or other obstructions. Thus, in COTM applications of TCP, the packet losses tend to be high, on the order of 15%-55% depending on whether the environment is open, rural or urban, and will lead to retransmissions,-thereby causing the TCP-based protocol to reduce its transfer rate. Indeed, most TCP/IP based applications, such as web access, email and ftp, as well as other applications related to voice and video, do not perform well over communication channels that link COTM terminals with fixed terminals, whether terrestrial or geostationary.
According to the conventional TCP protocol, when packets are lost, retransmissions are required according to certain rules and cause TCP to reduce its transfer rate. In addition, TCP uses a window management scheme in order to prevent congestion in the network and manage throughput. Throughput is defined as the window size “W” divided by the round trip time (“RTT”). Thus, at start-up, an initial window size “W” is set to be small, equal to one or two packets, and for a given RTT the throughput will be small. The window size W is increased exponentially (e.g., 50%) every round trip time as confidence in the capability of the link is developed, and the throughput increases accordingly. However, if a packet is lost, W is reduced exponentially (e.g., by 50%) and then increased linearly (e.g., by 0.5 packets) every round trip time, so that through put is decreased and then slowly increased. After multiple packet losses, W may be reduced to a minimum of 1 packet and then increased exponentially every round trip time until the window equals a percentage of the original window, and then is increased linearly every round trip time. For a COTM channel with periodic losses every 1-4 seconds, the instantaneous throughput is low since W stays close to 1. An example of conventional TCP performance over a satellite link is illustrated in FIG. 3. Time flows down the page, and the originating terminal is designated Tx (on the left) and the receiving terminal is on the right (Rx). Here a window of 8 kbytes and an RTR of 500 ms yield a throughput of 128 kbps, given the fact that all eight 1-kbyte packets of data require an acknowledgment (ACK). The throughput is severely limited, even though a 2 Mbps channel is used.
In the industry, signal outages often are compensated through the use of ARQ (Automatic Retransmission request) techniques. Link layer ARQ-S provides for retransmission of lost packets between the COTM terminal and the payload, e.g., a TCM satellite payload. In such case, the payload must maintain a separate ARQ session with every COTM terminal and the COTM terminal must maintain one ARQ session with the payload. Link layer ARQ-T requires retransmission of lost packets between COTM terminal and a fixed or other COTM terminal. In ARQ-T, the ARQ must be embedded in the terminal IP layer, so that payload can route ARQ packets. The fixed terminal must maintain a separate ARQ session with every destination COTM terminal and each COTM terminal must maintain a separate ARQ session for every one of its destination terminals.
Notwithstanding the potential benefits of ARQ techniques, ARQ interacts poorly with end-to-end TCP protocols, and even proxies. ARQ causes packets to get delayed and causes TCP to time out, reduce window sizes and invoke its own retransmissions. This unfavorable interaction is exacerbated when employed over long delay links, due to the long delay necessary for each retransmission. Moreover, ARQ will not fix end-to-end TCP limitations such as small TCP windows, small initial windows, slow windows increases, and lack of support for ECN (Explicit Congestion Notification), which is a TCP/IP standard that uses two bits in the IP header.
The TCP-ECN standard, particularly as detailed in RFC3168 (see Ramakrishnan et al, The Addition of ECN to IP, September 2001), specifies the use of two bits in the IP header of data packets to signal among routers and connection endpoints as to the existence of congestion. Congestion on a TCP network causes loss of packets. In order to identify congestion as a cause of packet loss, a sending TCP terminal can set an ECN-capable bit in the IP header of data packets, and intermediate routers can set the ECN bit in the IP header when they experience congestion while forwarding a transmitted packet. If the ECN bit is set, the receiver TCP terminal extracts the ECN bit and sends it to the sending TCP terminal in the TCP header of a subsequent ACK packet. The sending TCP terminal uses that information to slow down the transmission rate.
The number of packets of unacknowledged data that are permitted to be outstanding at any given time, before a congestion or failure condition is established, is specified by a value CWND. The value CWND serves as a congestion window and is decreased under certain conditions, such as the receipt of an ECN bit. According to the TCP standard, the use of ECN is always in combination with retransmission protocols that are engaged to overcome blockages and interference. However, the incompatibility of ECN with ARQ leaves a need for a solution to the combined congestion and interference problem.
Forward error correction also can be employed to simply ‘code through’ any outage length with the proper selection of code, code length and interleaving technique. This technique is not acceptable because of the inherent delay and traffic rate reduction required to compensate for losses due to long periods of degradation. For example, in a system subject to degradations of variable duration, the system designer would need to select a coding technique robust enough to compensate for the longest period of degradation. This coding, however, will result in unnecessary delay and/or lowered data rate during the times in which only short periods of degradation occur.
One solution to the foregoing problems lies in a TCP-based technique having a performance enhancing proxy (PEP) that serves to increase the performance of network protocols over degraded communication links. That TCP-PEP uses an effective retransmission protocol that is integrated into a performance enhancing proxy in order to compensate for degraded communication links. The TCP-PEP retransmission technique is modified and supplemented by additional features related to control of congestion, window size, connection negotiation, and accelerated establishment.